10.1.2 ガイド:Done の定義を育てる
#LeSS本
Done の定義は多面的で、密接なモニタリングを必要とし、育てる必要があるもの
Done の定義の完璧な目標は、組織がスプリントごと、またはそれよりも頻繁にプロダクトを出荷できるようになること
役割ごとの Done の定義を見る視点
Done の定義、そしてチームが以下に上手く Done の定義を達成できるかは、スクラム実行の健全性を評価する極めて重要な情報である
マネージャー
Done の定義が不完全である間は、 Done の定義は組織の変化をモニタリングし、管理する要のツールになる。
Done の定義を拡張することで、組織の変更や戦略的決定を導く
Done の定義の拡張は通常マネージャーの責任
マネージャーにはチームに Done の定義の拡張と改善の奨励が望まれる
チームが自分たちの Done の定義を拡張していれば、後でプロダクトの Done の定義を拡張しやすくなる
現地現物からの洞察がない限り、良い結果にならないので Done の定義を一方的に拡張してはならない(参考: 5.1.5 ガイド:現地現物)
チーム
Done の定義はチームの作業方法の改善を見つけるための情報を提供する。
全てのチームはプロダクトレベルの Done の定義を超えるよう、自分たちの Done の定義を独自で拡張することができる
e.g. Undone ワークのいずれかの項目についてチームで学習したり、改善方法を探索する(別の方法を探すとか)ことで、 1 つのチームが Done の定義を改善できる
プロダクトオーナー
弱い Done の定義がリスクと遅延の原因となり、プロダクトオーナーが価値を最大化し出荷時期の決定をする妨げとなる。良いプロダクトオーナーは組織のアジリティを高めるために改善に投資する。
e.g. 物品(実機とか)に投資したり、Done の定義を改善するために必要な PBI についてチームと議論する
スクラムマスター
Done の定義を拡張しないのは改善していない兆候。
e.g. チームが Done の定義を改善する方法について議論していないときに「チームが〇〇のスキルを改善することを妨げているものは何ですか?」のように尋ねる
Done の定義の拡張を決定する方法
マネジメントの議論と会議
マネージャーが自分自身に問う重要な質問は「どうしたら Done の定義を拡張できるか?」
組織のデリバリー能力を向上させるのはマネージャーの主な責務であり、 Done の定義は重要なツールとなる
レトロスペクティブ
レトロスペクティブで出てくる改善アイテムはチームメンバーの活動の改善や、成果と品質の向上、 Done の定義の拡張に向けての作業の改善かもしれない。
プロダクトレベルの Done の定義は全てのチームで共有されるが、各チームが Done の定義を拡張することを推奨している。
コミュニティ
コミュニティでの議論は、組織の動きやシステム的な課題を分析するのに最適な場で、 Done の定義を拡張する方法を見つけ出すのに良い。
特にスクラムマスターのコミュニティは、スクラムマスターはマネージャーと一緒に組織を変える責任があるため、発見された問題を確実に一緒に取り除く良い場となる(参考: 13.1.5 ガイド:コミュニティ)
組織の完璧な Done の定義の改善に終わりはない
より改善するなら以下を試してみましょう
スプリントを短くする
スプリント中に何度もリリースする
出荷可能なものよりも先まで拡張した Done の定義を作る
そういった Done の定義には市場の成功も含まれる
この場合アイテムは顧客がどのように使うかを計測するまで終わらない
リーンスタートアップではこれを「有効な学習」と呼ぶ